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Abstract 


The decisions that 
on the software side of the TAPR project 
have had a very strong impact on _ the 
implementation and success of that project. 
Following is a review of some the design 
decisions that were made long before coding 
started, and a chronicle their impact upon 
implementation and performance. 


were made up front 


Introduction 
Before the software description 
starts, lets run through a quick overview 


of the hardware. The microprocessor is a 
Motorola 6809; the memory complement is 24 
kilobytes of EPROM, 6 kilobytes of RAM, and 
32 bytes of electrically erasable ROM. The 
peripheral chips consist of a Mostek 6551 
asynchronous interface adapter, and a 
Western Digital 1933 HDLC interface chip. 
There is also an Mostek 6522 for clock 
support and onboard parallel 1/0. The 
potential of using a parallel port for 


term inal 1/0 is provided with a Motorola 
6820 parallel port chip. The computer 
system used as a_ software factory for the 
onboard software was an HP-64000 


microcomputer development system present at 
the University of Arizona. This system 
made possible the installation of the TNC 
software on the TNC hardware. 


software development cycle 
x25. The AT&T BX.25 
document was taken as a reference for LAPB 
(reference 1), and the AMSAT document 
(reference 2) was taken as a reference for 
the header construction. The transition 
tables in the BX.25 document were followed 
very closely for the connect/disconnect 
sequences, but the I-frame manipulation was 
implemented in other ways, as described in 
more detail later on. 


The entire 
was focused on 


Architecture 


The number one design choice was to 
write as much of the TAPR code in Pascal as 
possible. Pascal was chosen because it is 
a widely available high level language, and 
the existence of sophisticated compile time 


options for debugging implied the Pascal 
checkout could be started either on a big 
timesharing system or a microcomputer 


Pascal system. 


influenced the rest 
the most was to have 


The choice which 
of the implementation 


the high level Pascal code sit ina tight 
loop checking flags that are continually 
being set and reset by interrupt code 


assembly language. This design 
decision paved the way for implementation 
and checkout of the Pascal source without 
having to have the hardware actually 
running, and greatly simplified the design 
of the Pascal code since it did not have to 
deal with interrupts. There was also a 
complicating factor in that flags are 
continually being set and reset to schedule 
future actions in the Pascal code; that is, 
the main loop of code was a sequence of IF 
and CASE statements that check these 
important flags. The action taken by the 
code is not immediately apparent upon 
reading the code; you have to know the 
meaning of the flags being manipulated,. 


written in 


The next design hurdle was_ the 
buffering; how many buffers should there be 
and what mechanisms were to be used to move 
data from one buffer to another? The main 
task, being a TNC, needed only two buffers, 
one for the incoming data flow and one for 
the outgoing data flow, and it was thought 
at one time that only two buffers would be 
needed. Once digipeating and control 
functions were considered, it was clear 
that four buffers were needed ~ there had 
to be a way to shuttle HDLC input data to 
the HDLC output queue and a way of talking 


terminal input data for commands, acting 
upon the commands, then printing a response 
to the terminal. The software was then 
broken up into four distinct sections; each 
section moves data from one buffer to 
another, with the possible side effects 
such as parameter changes. One section 
moved data from the HDLC input ring to the 
terminal output ring, another moves data 
from the terminal input ring to the HDLC 
output ring, a third took data from the 
terminal input ring and produced status 
messages in the terminal output ring, and 


the digipeating process move HDLC frames 
from the HDLC input ring to the HDLC output 
ring. 


The next choice was to have the 
software 'know' as little as possible about 
the half duplex nature of the radio link. 
Previous implementations such as Vancouver 
Area Digital Communications Group protocol 
(VADCG for short) had used the poll/final 
bit in messages to turn the link around and 
have the receiving side turn into’ the 
transmitting side. I did not fully 
comprehend the use of the poll/final bit in 
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this manner, 
bit certainly 
usage. The 

"when do I 
stated: Only 


conflicted 


send" problem 
acknowledge 


and this use of the poll/final 
with 
design decision chosen for this 


the LAPB 
can be simply 
receipt of 
the modem 


messages or send 
signal data carrier 
or the data carrier 
dropped at least once since 
message. This rule means 


messages when 
detect is not present, 
detect 


signal has 
receipt of a 
that message 


acknowledgements will be generated once for 


every sequence of 
that there is a 
traffic before any 
up for transmission. 


break in 


information frames, 


and 
the received 


new messages are queued 


has its own peculiarities, and the flag 
checking/clearing activity associated with 
each peculiarity will be covered. 


The first stream of data is the HDLC 
input stream. Here a global variable 
exists which always contains the upic input 
top frame size, and is zero if there are no 
HDLC input frames placed into the HDLC 
input buffer and not yet processed by the 
Pascal program. The portion of the Pascal 
code that handles HDLC input notices that 
the variable is nonzero, and calls a low 
level routine which will move the HDLC data 
from the input ring buffer into a private 


Consequences of the architecture 


The Pascal implementation on _ the 
HP-64000 development system was not a full 
ISO standard Pascal. The major difference 
dealt with character strings; the HP Pascal 
had a STRING data type whereas the ISO 
standard has only arrays of characters. 
Unfortunately when the HP system writers 
adopted the STRING data type, they threw 
out completely any compatibility with ISO 
standard programs - character strings 
longer than one byte could not be used. 
This problem was ‘solved' by including all 
character strings into one area of memory 
in EPROM. All references to constant 
strings had to reference th name of the 
array containing the data in this read only 
data area. 


The Pascal code was checked out on two 
different computer systems prior to being 
installed on the TAPR board. The systems 
were a 36 bit mainframe and an 8 bit micro. 
The 36 bit mainframe checkout used routines 
to loop back HDLC input and output together 
in software; this allowed the software to 
connect to itself and allowed the basic 
logic to be checked out; all of this 
checkout was greatly speeded up via the 
symbolic debugger on the mainframe, The 8 
bit micro allowed on the air tests with 
VADCG boards, and was invaluable in shaking 
down more basic logic problems. Again the 
routines to interface to terminal and HDLC 
I/O had to be changed to reflect the 
routines existing in the 8 bit micro 
system, but this is a pretty easy task to 
accomplish, The result of this staged 
checkout was a very robust implementation 
Of 25% There were bugs in the Pascal 
code, but they were only evident under 
extreme conditions. 


Implementation of the architecture 


of data flow: 
I/O and two 
Knowing when 
input streams 


are four streams 
for HDLC 
terminal I/O. 


There 
Two directions 
directions for 
there is data present in the 
and when there is enough room in the 
buffers for more characters in the output 
streams is handled by global variables. 
These variables are generally set by 
interrupt routines and reset when low level 
routines called by Pascal manipulate data 
associated by the flags. Each data stream 
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Pascal buffer for further examination. 


For 


HDLC 


output, 


variable which contains 


bytes in the HDLC output ring buffer, 
checked 
generated, 


cell is 


frame is 


enough room in 


for 


the potential 
generation ofthe 


befor 


and 


there 


is a global 


the number of free 


e any 
if 


This 
HDLC output 
there is not 


the HDLC output ring buffer 


output frame, 
output frame is deferred 


then the 


by simply not clearing the flags that cause 


the 


output frame to 
case of digipeated 


enough room in 


for 


the 


be generated. 
frames, 
the HDLC output 
digipeated 


if 


frame, 


In the 
there is not 
ring buffer 
then the 


digipeated frame is simply forgotten. 


Terminal 


output, 
PSasa 6g 


queue up 
space 
to 
having 

count is 
when = X- 
port. 


queue 


but ther 
lobal 
number of bytes 
output ring buffer. 
terminal data will always wait for 


the 


to 
frames 


output i 


s simi 


lar to HDLC 


ar 
variable 


differ 
which 


neces. There 
contains the 


currently available in the 


available in the 
character, 
the variable output = ri 
avoid waiting for buffer space 


come in 


When an I-frame 


The routi 


output 


The purpose 


ne called to 
"buffer 
in 
ng free byte 


ring 


on the HDLC input 


comes i 


data portion too big to buffer, 
ignored and the HDLC message 


the frame are 


uw RNR" 
This 

callable 
code, 


debug 
any 
one 


and 


async 


from 


does 

parameter displays, 
routines, 

of these activities 


would care 


output 

anywhere 
get 
It was 


if 


the 


n that has a 
the data in 


is scheduled for future transmission. 
routine is 


freely 


within the Pascal 


called 
hex dumps., 


as a part of 
and internal 


decided that when 


were 


Pascal 


going on, no 
code was 


spinning while waiting for more room in the 
async output buffer. 


Now we come to the most interesting of 


the buffering problems, 
The nature of X.25 
complete 
From the tight 

that 
could not 


to 
once. 
was 

I-frames 
else 


seven 


clear 


in memory. 


the 


The 


terminal input. 
is that there can be up 
I-frames 

RAM limitations, 

input data for 
be duplicated anyplace 
solution chosen 


in flight at 
it 
these 


this 


time around was to build a table describing 


the 
ring 
long, 
buffer, 


point. 
because 


active portion 
buffer. 
and 


The 


that is 


each 

start pointer into 
and a data 
table is 
the modulus 


of 
The 
entry 


tabl 


the 


terminal 


input 


is 


ight entries 


consists of a data 


the terminal input ring 
length frem that start 


ntries long 


ight 


for the X.25 


sequence numbers , and these X,. 25 sequence 
numbers serve aS indexes into the table. 
Part of the routine activity is to check to 
see if a new I-frame can be generated, and 
if sothen a check is made for data to fill 
the I-frame. This checking is performed by 
calling a routine which returns a removal 
pointer anda size for data (if any) 
present within the terminal input ring. If 
there are data present, then the size will 
be nonzero, and another table entry can be 
constructed to describe an P-frame in 
flight. When I-frames get acknowledged the 
data space occupied in the terminal input 
ring buffer is marked no longer in use by 
advancing to the next sequence number and 
by changing a pointer , allowing reuse of 
the memory. One consequence of this design 
choice on input buffering is a "selective 
reject" (asking for fills) , becomes a more 
difficult job to implement than if the 
other feasible approach of using linked 
lists had been made (It should be noted 
that selective reject is not part of X.25). 


The next area that was simplified by 
the design decisions is the generation of 
HDLC frames for information transfer. 
There is a definite priority in x.25for 
the kinds of frames that have to be sent, 
The priority scheme is implemented by the 


order in which flags are checked. These 
flags are generally set in the HDLC input 
routine, but may be set by anyone to 


schedule HDLC output. The flags that are 
checked and the order in which they are 
checked are: The send RNR flag (set when 
terminal buffer space gets low) to senda 
RNR frame, the send REJ flag (set when an 
out of order frame is received) to send a 
REJ frame, th received RNR flag must be 
reset (set when an RNR frame is received) 
to send an I-frame, the send RR flag (set 
when I-frame received) to send an RR frame. 
This section of code is also where the 
hal f-duplex decision must be made. The 
code to generate these output frames is 
only executed if the modem signal DCD (data 
carrier detect) is low or if the DCD signal 
dropped after any of the flags scheduling 
RNR, REJ or RR. frames were set. This 
simple test is all it takes to prevent the 
sending of an RR frame for every I-frame 
received. Notice also that with the order 
in which the flags are checked, sending an 
I-frame will be attempted before sending an 
RR frame, so that if both sides have 
I-frames to send, then there are no RR 
messages sent when an I-frame would also 
acknowledge receipt to the other side. 


Another detail that was made quite 


easy by the "no interrupts in Pascal" 
decision was the handling of multiple 
software timers. Actually, there are only 


two timers, the beacon timer and X.25 timer 
tl, but they are handled exactly the same 
way. The generalized timer code is 
implemented via a Pascal structure; this 
structure contains an expiration time and a 
Boolean flag that indicates whether or not 
the timer is running. "Time" is used 
loosely, for the only way the Pascal code 


2.23 


is aware of the passage of time is by 


looking 
The time 


a one per second rate by an = assembl 


language 


timer needs to be started, its expiratio 


time is 


plus the number of seconds in the time 
interval, 


at yet another global variable. 
global variable is incremented at 


y 
interrupt routine. Whenever 

n 

set to the time global variable 

£ 

n 


and a Boolean flag is set withi 


the timer structure to indicate the clock 


is active, The big loop of code that is 
continually checking flags now has to check 
the timers for expiration, and this is 
quite easily done by comparing the global 


variable 
the timer 


time with the expiration time in 


Debugging and checkout 


As 
selected 
HIP-64000 


ubset of ISO standard Pascal was 
which would work both with the 
compiler and the two systems that 


I had available for writing and checkout, 
The real reason for this subset decision 


was to allow as much checkout of the 
software as possible in a_ friendly 
environment. The "no interrupt code in 
Pascal" decision made possible the 


replacement of low level routines in 


assembly 


language with routines written in 


Pascal which could invoke standard Pascal 


I/O. On 


the mainframe, a dummy set: of HDLC 


input and output routines was written to 
loop back the HDLC output internally (from 
the Pascal programs point of view) to the 


HDLC in 
existing 


put. On the §8 bit micro system, 
routines for MDLC input and output 


were modified to use new calling sequences 


and the 


Pascal code was actually executed 


on the air. In both debugging testbeds, 
the clock was simulated by incrementing the 
global variable holding the second tick 


whenever 


the code in the main loop noticed 


the system time of day change froma 


previous 


value. These sets of routines 


allowed checkout of the major logic flow of 
the Pascal software under a _ symbolic 


debugger, 


This self-test arrangement was 


extremely valuable, and allowed about 
ninety percent of the bugs in the Pascal 


code to 


be eliminated under the friendly 


environment of the symbolic debugger. Not 
everything could be checked, and the things 


that could not be checked were not: setting 


flags for the low level routines (which 
didn't exist) or missing transitions in the 


state/event table that were never exercised 
during this self-test. One clear fallout 
Of the debugging procedure was 


transportability, because the software was 


running 
before 

TAPR TNC 
Summary 


The 


on two different Pascal systems 


the TAPR TNC software even net the 
hardware. 


broad design decisions that were 


made before implementation of the TAPR TNC 


software 


served as an aid in 


inplementation, supplying a framework that 
wceuld support the detailed coding process. 
These decisions were made in the light of 


previous 


experience (and mistakes) in the 


implementation of three other systems 
similar to X.25. There were other choices 
that could have been made to supply the 
implementation framework, but my intent was 
to illustrate the decisions which made the 
TAPR INC software almost write itself. 
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